Wireguard Overview
IPsecと比較したときに、以下の項目を目標としている より高速
よりシンプル
より引き締まった (leaner)
より便利な
組込みからスーパーコンピュータまで、多くの状況で利用できる汎用目的のVPNとしてデザインされている
当初はLinuxカーネルとしてリリースされ、現在では以下のクロスプラットフォームなデプロイをサポートしている Windows
macOS
BSD
iOS
Android
現在も開発が進行中である一方、業界で最もセキュアかつ使いやすい、そしてシンプルなVPNソリューションとみなされている可能性がある
Simple & Easy-to-use
設定とデプロイがSSHと同じくらい簡単であることを目標としている
SSHの鍵交換とまったく同じように、極めてシンプルな公開鍵の交換によりVPNのコネクションは確立され、残りのすべてはWireGuardにより透過的に処理される
Moshのように、IPアドレス間のローミングを行う能力も有する 以下は必要ない
コネクション管理
ステートの管理・考慮
デーモンの管理
具体的に何が起きているのかに対する懸念 (worry about what's under the hood)
基本的な一方でパワフルなインターフェイスを提供する
Cryptographically Sound
WireGuardは最先端の暗号化手法を用いる。例えば:
併せてセキュアで信頼できる構造を用いる
これらはコンサバかつ合理的な選択であり、暗号の専門家によってレビューされている
Minimal Attack Surface
WireGuardは「実装の平易さ」とシンプルさを念頭に置いて設計されている
非常に少ない行数のコードで簡単に実装でき、セキュリティの脆弱性に対する監査・検査を容易にすることを意味する
Swan/IPsecやOpenVPN/OpenSSLのような猛獣 (behemoths) と比較すると、これらの巨大なコードベースに対する監査は、たとえ大規模なセキュリティエキスパートのチームであっても計り知れないほどのタスクである一方、WireGuardは一個人でも網羅的にレビューすることが可能です。 High Performance
非常に高速な暗号化のプリミティヴと、WireguardがLinux Kernelの内部に存在するという事実の組合せは、セキュアなネットワーキングが非常に高速にできる可能性があることを意味する
スマートフォンのような小さい組み込みデバイスや、高負荷なバックボーンルーターのようなデバイス、どちらの用途にも適す
Well Defined & Thoroughly Considered
WireGuardは長期間かつ完全に、学術的なプロセスによって検討された結果である
テクニカルホワイトペーパーも存在する
Conceptual Overview
もしプロトコルに興味がある場合は？
更に詳細について知りたい場合はテクニカルホワイトペーパーを参照のこと
WireGuardを新しいプラットフォームに実装したい場合は？
WireGuardはIPパケットをセキュアにカプセル化し、UDP上を通す
WireGuardインターフェイスを追加し、自身の秘密鍵とピアの公開鍵によって設定することで、それら越しにパケットを送信できる
鍵の配達およびpushされたコンフィグについてはWireGuardのスコープ外
これらへ別のレイヤで行うほうが良い
対照的に、sshとmoshのモデルをより真似る
双方は、互いの公開鍵を持っているため、インターフェイスを介してパケットの交換を開始できる
Simple Network Interface
WireGuardはネットワークインターフェイスを追加することにより動作する
wg0, wg1みたいな感じで……
このネットワークインターフェイスは ifconfig(8) や ip-address(8) のような通常のコマンドによって設定でき、またrouteの設定も route(8) や ip-route(8) のようなものででき、他のものも同様、つまり一般的なネットワーキングのユーティリティによって設定できる
特別なWireGuardのインターフェイスにまつわる側面は、wg(8) によって設定されるということ
このインターフェイスはトンネルインターフェイスとして動作する
WireGuardは公開鍵とremote endpointsをIPアドレスと紐付ける
interfaceがパケットをピアに送信するとき、以下のようなシークエンスを経る
1. このパケットは 192.168.30.8 を対象としている。どのピアを使えば？ ちょっと待って……オーケー、ABCDEFGHがピアです。
もしくは、適切なピアがない場合はパケットをdropする
2. IPパケット全体を、ABCDEFGHの公開鍵を使って暗号化する
3. 何がピア ABCDEFGH ピアのリモートエンドポイントか？ ちょっと待って……オーケー、UDP 216.58.211.110:53133
4. 2で暗号化したバイト列をインターネット越しに、UDP 216.58.211.110:53133に対して送信する
interfaceがパケットを受信したときは以下が発生する
1. UDPで、98.139.183.24:7361からパケットを受信した
2. このパケットはピア LMNOPQRS に対して適切に復号化および認証がされた。オーケー、ピア LMNOPQRS の直近のインターネットエンドポイントが UDP 98.139.183.24:7361 であることを思い出す
3. 復号化したところ、平文パケットは 192.168.43.89 からのものであった。ピア LMNOPQRS は 192.168.43.89 としてのパケットの送信を許可しているか？
4. 許可している場合、パケットはインターフェイスによって受理される。そうでない場合は破棄する。
Cryptokey Routing
Cryptokey RoutingはWireGuardコンセプトの心臓
トンネル内で許可された公開鍵とトンネルIP addressesの紐付けによって動作する
それぞれのネットワークインターフェイスは秘密鍵とピアのリストを持つ
それぞれのピアは公開鍵を持つ
公開鍵は短かく簡潔であり、互いに認証するためにピアによって使われる
これらは、シェルサーバーにアクセスするためにSSH公開鍵を友人に送信する方法と同様に、任意のout-of-band methodを用いて設定ファイル内で使用するために渡すことができる
code:example server config
PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=
ListenPort = 51820
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
AllowedIPs = 10.192.122.3/32, 10.192.124.1/24
PublicKey = TrMvSoP4jYQlY6RIzBgbssQqY3vxI2Pi+y71lOWWXX0=
AllowedIPs = 10.192.122.4/32, 192.168.0.0/16
PublicKey = gN65BkIKy1eCE9pP1wdc8ROUtkHLF2PfAqYdyYBz6EA=
AllowedIPs = 10.10.10.230/32
サーバー設定では、それぞれのピア (クライアント) はパケットを、許可されたIPに対応するリストと一致するソースIPを使用して、ネットワークインターフェイスに送信することができる。
例えば上記サーバー設定において、peer gN65BkIK...からのパケットがサーバーで受信され、復号化および認証された後、もしそのソースIPが 10.10.10.230で、インターフェイスによって許可されている時はパケットは受理され、そうでない場合は破棄される (この例では許可される)
サーバー設定では、ネットワークインターフェイスがピア (クライアント) に対してパケットを送信したい時、どのピアにパケットを送信するかを判断するために、パケットの宛先IPを見たのちそれぞれのピアが持つ許可IPのリストと宛先IPを比較する
例えば上記サーバー設定において、ネットワークインターフェイスが宛先IP 10.10.10.230 のパケットを送信するように要求された場合、パケットはピア gN65BkIK... の公開鍵を使って暗号化され、そのパケットはピアの直近のインターネットエンドポイントに対して送信される
code:example client config
PrivateKey = gI6EdUSYvn8ugXOt8QQD6Yc+JyiZxIhp3GInSWRfWGE=
ListenPort = 21841
PublicKey = HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw=
Endpoint = 192.95.5.69:51820
AllowedIPs = 0.0.0.0/0
クライアント設定では、その単一のピア (サーバー) は任意のソースIPを用いて (クライアントの) ネットワークインターフェイスに対してパケットを送信できる (0.0.0.0/0 はワイルドカードであるため)
例えば上記クライアント設定において、Higo9xNz..からのパケットを受信したとき、もし復号化と認証が成功し、任意のソースIPが存在した場合、インターフェイスによって受理される。そうでない場合は破棄される
クライアント設定では、ネットワークインターフェイスがパケットをその単一ピア (サーバー) に送信したい時、単一ピアのためのパケットを任意の宛先IPアドレスとともに暗号化する。
例えば上記クライアント設定において、もしネットワークインターフェイスがパケットを任意の宛先IPへと送信するように要求された場合、パケットを単一ピア (サーバー) の公開鍵 Higo9xNz.. によって暗号化し、単一ピアの直近のインターネットエンドポイントに対して送信する
言い替えると、
パケットを送信する際、許可IPリストはルーティングテーブルのような挙動をする
パケットを受信する際、許可IPリストはアクセスコントロールリストのような挙動をする
これが我々 (WireGuard member) の言うところの Cryptokey Routing Table である
「簡潔な公開鍵と許可IPsの紐付け」
IPv4とIPv6の任意の組み合せはあらゆるフィールドで利用可能である
WireGuardは、もし必要であれば一方を他方の中へ完全にカプセル化することが可能
WireGuardsインターフェイスにより送信されるすべてのパケットは暗号化および認証が成されており、ピアの識別子とピアの許可されたIPアドレスの間には緊密な紐付けがあるため、システムの管理者はIPsecの時のように複雑なファイアウォール拡張を必要としない。
むしろ、「これはこのIPからのもの？ このインターフェイス？」などといった単純な一致による判断が可能であり、それによりセキュアかつ信頼できるパケットであることを保証できる
これはネットワーク管理とアクセス制御の偉大なシンプル化であり、またiptablesのルールが意図通り正しく動いていることをより確実に保証する
Built-in Roaming
クライアント設定は単一ピア (サーバー) の 「初期エンドポイント」を含むため、暗号化データを受信する前に、暗号化されたデータの宛先を認識できる
サーバー設定はpeers (clients) の初期エンドポイントを持たない。
サーバーはpeersのエンドポイントを、正しく認証されたデータの送信元を調べることにより検出するため
もしサーバー自身が自分のエンドポイントを変更し、クライアントにデータを送信した場合、上と同様にクライアントは新しいサーバーのエンドポイントを発見し、設定を更新する
サーバー・クライアントの両方は、暗号化されたデータを、データの復号に成功した直近のIPエンドポイントへと送信する
これにより、両端において完全なIPローミングが存在する